The present invention relates to interaction monitoring systems used in electronic commerce. More particularly, this invention relates to automatically creating and maintaining, with an interaction monitor, interaction history data for a long running application wherein the interaction history data can be accessed by the application.
With the substantial increase in use of the Internet and, particularly, the World Wide Web (xe2x80x9cWebxe2x80x9d), electronic commerce is emerging as an important tool for service providers. Such applications may be long running, perhaps spanning over many hours and days, where not only a single interaction may be asynchronous, i.e., a long time may pass before a response to a request is returned, but related interactions may be dispersed in time. Consequently, a need has developed for a system of providing long running service applications whose interaction history is maintained for application access so that compensation of an earlier service request is a capability.
Monitors are software systems that support simple creation and execution of application programs with complex requirements. They manage underlying resources (both physical computing resources as well as logical resources, such as data files) which the applications require and monitor the access to these resources in an orderly fashion. There are many types of monitors (e.g., transaction processing and security monitors) creating different application execution environments and ensuring different properties for these applications.
FIG. 1 illustrates a conventional transaction processing (TP) monitor system for supporting transactional applications. Transactional applications access various data and logical resources such that access to these resources needs to be controlled to enforce certain properties, namely atomicity, consistency, isolation and durability (ACED). A TP monitor provides an execution environment for automatically ensuring these properties. The transactional applications T1130 and Tn 135 are registered with the TP monitor 120. There can be many such transactional applications. Upon receiving a request 110 for execution of one such registered application (e.g., Tn 135), the TP monitor 120 allocates necessary physical resources to the system and instantiates an instance, Tnj 152, of the application Tn 135. The TP monitor 120 passes the input parameters received with the request to the application instance 152 over path 116. Each application instance is referred to as a transaction. Thus, transactions T11150 and T112151 are instances of the registered application T1130. Once a transaction is completed, the results 153 are returned by the monitor 120 to the client application. In a different type of monitor environment, the application instance may be started and stopped locally under administration control.
Transactions access logical resources (e.g., databases) maintained by the resource managers 140 and 141. The monitor 120 intercepts all access to these resources by the transactions and maintains a history of access to these resources in their log 160. The monitor 120 also detects any application failure either due to a failure of the underlying computer system or due to software errors. As indicated hereinabove, the TP monitor system supports execution of transactions ensuring ACID properties. Atomicity refers to the property where all updates by a transaction to the monitored resources are made permanent only if the entire application succeeds. Incomplete execution of the application, due to any failure, will result in the restoration of the state of the resources to that state which existed prior to any access by the transaction. The TP monitor and/or resource managers maintain a history of accesses by all transactions to achieve this restoration of state. However, this history creation/maintenance is performed automatically by the monitor 120 without any knowledge of or assistance from the applications. Ensuring the other three properties (i.e., Consistency, Isolation and Durability) also requires monitoring any accesses to the controlled resources and making use of the history. Thus, the TP monitor provides reliability and execution support to applications by providing a system guarantee that all persistent effects are removed on failure.
Many other types of access monitors exist for ensuring a subset of these or other access properties (e.g., security, access control). In all cases, the underlying monitor intercepts access to the monitored resources by the supported applications and exercises certain access monitoring logic based on the present access state. However, in all cases, the applications are unaware of the details of the underlying operations of the monitor, other than the semantics of these properties guaranteed by the monitor. Therefore, in the TP monitor and the other similar access monitors of the prior art, the applications do not have direct access to the interaction history maintained by the monitor.
This conventional monitoring is implemented in many different ways. The monitoring logic may be distributed across many computer systems. Additionally, the applications may execute in a system different from the monitor systems. FIG. 2 illustrates the working of a transactional application executing outside the monitor systems. T1230, T2235 and T3240 represent three instances (transactions) of transactional applications. These transactions access the logical resources monitored by the servers 210 and 215. All accesses to these resources by these transactions 230, 235 and 240 are referred to as transactional remote procedure calls (TRPCs) 250 through 255, since the access to the monitored resources follows the ACID properties. The monitoring software in the servers 210 and 215 coordinates the monitoring logic to achieve these properties. As in FIG. 1, the servers 210 and 215 maintain transaction logs 220 and 225, respectively to maintain various properties.
In contrast to typical ACID transactional applications, workflow applications are long running and may be created as multi-step applications consisting of independent application steps. Such applications are reliably executed under a workflow monitor. Workflow systems, e.g., IBM""s Flowmark product, maintain a persistent record of process and process instance state for the purpose of controlling (starting and stopping) the activities in the process flows. The state management functions of a conventional workflow system are illustrated in FIG. 3. Workflow systems must store both the process flow form (for managed processes) and the state of each process instance. In FIG. 3(a), elements 301 through 316 show information which would be stored defining a process flow. In FIG. 3(b), elements 317 through 328 describe state information which would be recorded for each process instance.
In FIG. 3(a), the process flow PF includes activities or processing action blocks 301 through 306 which the workflow system is responsible for controlling. The arrows 307 through 315 represent data and control flows so that arrows 307 and 315 represent the start and the end of the process flow, respectively. The other data/control flow arrows, 308 through 314, show how the output data produced by the completion of one activity will be made available as input to other activities. The workflow system is responsible for scheduling activities as soon as all necessary inputs are available for them and managing the distribution of data to activities following the data/control flow arrows in the process flow graph. Element 316 is a pool of resources such as skilled agents. The work flow system, when starting an activity, may also be required to select an available and appropriately skilled resource to perform the activity. To carry out the above functions, workflow systems store a persistent record of the information illustrated above for process flow PF.
In addition, in order to be able to control instances of the defined process flow, workflow systems also maintain state information on each process flow instance. This information is usually persistent (e.g., stored on disk) so that business process flows can be recovered after a system failure, and because the process flows may be long lived. In FIG. 3(b), elements 317, 318 and 319 schematically represent state information for separate instances PF1, PF2 and PF3, respectively, of the process flow PF. Element 320 is an expanded view providing more detail of state information on process flow instance PF1317. PF1""s state is described by providing an activity instance state for each activity defined in the flow. The process flow PF consists of 6 activities. Elements 321 and 322 show that PF1""s state includes a state for an activity A1 instance, PF1.A1, and an activity A2 instance PF1.A2. This pattern is repeated for the other activities in the flow. Element 323 is an expanded view of the state information for each activity instance. Typically, this might consist of: the input values 324 for the activity, the outputs 325 produced if it is already complete, whether or not the activity has been started 326, any specific resource 327 assigned to process the activity, and whether or not the activity has completed 328. The above highly structured collection of state information enables a workflow system to schedule and control activities following the defined process flows.
The hereinabove-described ACID properties of conventional TP systems have less relevance in the new workflow-dominated Internet environment where end users are initiating potentially global business interactions, each one of which may span multiple independent enterprises. A participating organization cares much more about what it has committed to deliver and is legally obligated to do, rather than whether its database is consistent with the databases in partner organizations. Practical multiparty business interactions on the Web are more concerned with (1) have the business actions been durably recorded?, (2) what application defined compensation actions are available if cancellation is desired?, and (3) what automatic expiration periods are required by the business and legal agreements between the parties?
Event monitoring is a conventional practice used in many computer applications where a record of at least some of the events occurring in the computer program is generated to help with subsequent analysis of a particular execution, data mining of executions to extract additional useful information, auditing or other purposes. These event logs are usually persistent since they are used outside the program by other analysis processes and do record some information about which xe2x80x9cstatesxe2x80x9d occurred during execution of the application.
FIG. 4 illustrates a conventional event logging system. Element 401 represents a computer application program. A particular execution 403 of program 401 is also shown. This execution 403 consists of a sequence of events 404 through 411. The timeflow arrow 402 shows that these events occur as a sequence in time. These events may be monitored and recorded on some persistent log to allow offline analysis. This monitoring is illustrated with four example services: a debug service 412, an execution trace service 413, a performance monitor 414 and a message or console log 415. Each of these services captures and makes a record of the events in the execution of the program 401 relevant for its purposes. The events usually are saved persistently on logs 416 through 419. The event logs are then made available for either automated or manual offline analysis. This analysis can include debugging 420 during development of the computer application 401, an audit 421 of executions of the application 401, analysis of the program""s execution performance 422 and data mining 423 to extract useful business information from the sequence of events occurring during the program""s execution.
In these conventional event logging services, the use of the event logs is not coupled directly with execution of the application or program which generated the event sequence. Therefore, the application does not have access to the event logs.
Thus, there is a need for a monitoring system which provides application access to the interaction data of a long running application.
There is also a need for a monitoring system that provides and manages simple application defined compensation of actions.
Finally, there is a need for a monitoring system which provides end users with a reliable view of canceling, reissuing and modifying particular service requests.
The present invention provides a new form of monitor and interaction history to meet the new requirements of business service applications in an e-commerce, networked computer environment. The conversation monitor of the present invention manages the execution of a set of business service application instances executing on a business service engine. It monitors all interaction between these business service applications and between other services and parties executing elsewhere. The monitor automatically creates a persistent record of these interactions as the interaction history, without the need for explicit instructions to do so in any of the business service interactions. Finally, the monitor starts new business service interaction instances in response to requests from clients for new conversations and stops the instances at the request of either the client or the monitor.
The interaction history of the present invention is a persistent record of all interactions. It is accessible to the business service applications, as well as to the conversation monitor. The interaction history is structured to: provide convenient information to the business service application concerning its long term state, enable the conversation monitor to automatically support cancellation and compensation of complete conversations, specific actions and groups of actions; provide clients with a stable record of their interactions with the business service; and provide a base for enforcing service contract agreements in which this service is a partner.